One-off - Check In

This flow is followed by merchants who wants to integrate Maypay directly into their devices software. Thanks to the API offered by the Maypay service, third-party software can request the list of pending payments for a specific store or for all the stores associated with a specific merchant account. The use case that best fits this flow is described here Physical Store - Check In.

caution

A discount of 100% off the gross amount of the purchase should be applied to amounts associated with winning payouts. The amount is in fact paid by Maypay while the user does not pay. The amount paid by Maypay for each winning outcome is in the form of a reversal from the commissions retained by Maypay and allocated to the prize pool.

Read more

danger

If you encounter an error while accepting or refusing the payment, you can retrieve the transaction using the getTransactions API and check its status

APIs required

• Get Pending Payment Requests
• Accept Payment Request
• Refuse Payment Request

Sequence Diagram

sequenceDiagram participant MA as Maypay App participant MS as Maypay Server participant MES as Merchant Server participant MC as Merchant Client rect rgb(255, 255, 255) MA->>MA: Select Store MA->>MS: createPaymentRequest activate MS MS->>MA: success - Paymente Create deactivate MS MC->>MES: Select Maypay as Payment Method activate MES MES->>MS: GET - getPendingPaymentRequests activate MS MS->>MES: 200 OK - Pending Payments deactivate MS MES->>MC: Pending Payments deactivate MES MC->>MC: Show pending payment alt Accepting MC->>MES: Accept Payment activate MES MES->>MS: POST - acceptPaymentRequest activate MS MS->>MES: 200 OK - Payment accepted MS->>MA: Payment accepted deactivate MS MES->>MC: Payment accepted deactivate MES else Refusing MC->>MES: Refuse Payment activate MES MES->>MS: POST - refusePaymentRequest activate MS MS->>MES: 200 OK - Payment refused MS->>MA: Payment refused deactivate MS MES->>MC: Payment refused deactivate MES end end

How to test

API integration and testing is made easier by a Sandbox Test Environment provided by Maypay. This environment simulates the creation of transactions and interaction with the buyer, giving the possibility to decide what the payment outcome will be.

Prerequisites

There is no difference between production and sandbox API endpoints. The distinction between production and sandbox API calls is made by the type of API Key. API Keys can be created via the merchant portal Maypay Business and can be of 2 types:

• Production: API Keys to be used for the production environment
• Sandbox: API Keys to be used for the sandbox environment

Test Check-In payment flow

In this flow, transactions are created directly by the buyer, then the merchant through the getPendingPaymentRequests obtains the list of pending payments and decides to accept or reject the payment.

On the other hand, when the call is made with an API key of type sandbox, the getPendingPaymentRequest returns a list of dummy transactions that have the following IDs, based on the payment result you want to simulate:

• Accepting:
  • sandbox_win_transaction: The transaction will be accepted and the payment will be won via Maypay.
  • sandbox_lose_transaction: The transaction will be accepted and the payment will be paid via Maypay.
  • sandbox_timeout_transaction: The transaction cannot be accepted because it has expired.
  • sandbox_cancel_by_merchant_transaction:The transaction cannot be accepted because it was previously refused by the merchant.
  • sandbox_cancel_by_buyer_transaction: The transaction cannot be accepted because it was previously cancelled by the buyer.
  • sandbox_error_transaction: The transaction cannot be accepted due to a generic error.
  • sandbox_successful_refund_transaction: The transaction cannot be accepted because it was previously accepted and refunded.
  • sandbox_failed_refund_transaction: The transaction cannot be accepted because it was previously accepted and then the refund failed.
• Refusing:
  • sandbox_win_transaction: The transaction will be refused.
  • sandbox_lose_transaction: The transaction will be refused.
  • sandbox_timeout_transaction: The transaction cannot be refused because it has expired.
  • sandbox_cancel_by_merchant_transaction:The transaction cannot be refused because it was previously refused by the merchant.
  • sandbox_cancel_by_buyer_transaction: The transaction cannot be refused because it was previously cancelled by the buyer.
  • sandbox_error_transaction: The transaction cannot be refused due to a generic error.
  • sandbox_successful_refund_transaction: The transaction cannot be refused because it was previously accepted and refunded.
  • sandbox_failed_refund_transaction: The transaction cannot be refused because it was previously accepted and then the refund failed.

tip

Use the transactionId field of the acceptPaymentRequest and refusePaymentRequest API to indicate one of the above-mentioned transaction IDs. For example:

transactionId: "sandbox_lose_transaction"

How to test getTransactions

Using a sandbox type API key, the getTransactions API returns a list of dummy transactions in order to test the logic behind the transaction search filters.

To simulate the real case as closely as possible, storeId, storeName and merchantId of the response match those of the stores you create and each of them return different transactions. In addition, the transactionId unlike the sandbox functions mentioned above, is a unique ID similar to that of real transactions.